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Data Pipoy oem Meat amateur radio 
using equencies has recently become 
more effective and enjoyable due to a new 
communication Vidor ne called PACTOR. 
PACTOR was developed by two 
enterprising German amateurs, D 

and DF4KV. This article is based on the 
information provided by these gentlemen 
in their various writings. 

PACTOR Features 


PACTOR was designed to overcome the 
shortcomings exhibited by both packet and 
AMTOR in HF operation while remaining 
affordable for the average amateur 
operator. 


- Error-free data transmission (less than 1 
x 10S) 


- True binary data transmission 

- Efficient use of channel capacity 

- Good interference tolerance 

- Requires only 600 Hz channd bandwidth 


- Complete visibility of sending and 
receiving callsigns 


Why PACTOR? 


HF propagation is characterized by 
multipath propagation which induces ‘bit 
stretching’ and phase distortions, fading, 
impulse noise, and interference by other 
stations, among other obstacles to 
communication. 


The PACTOR mode is similar to AMTOR 
which is good for ordinary HF 
commumcation. Both use half duplex 
ARQ; packets (blocks) of data carrying the 
information are acknowledged with short 
‘receipt’ signals by the recaving station. 
When errors occur, the receiver can 
request the repetition of a packet with 
relevant control signals. 


PACTOR uses a MASTER/ SLAVE 
phasing like AMTOR. The SLAVE clock 
1s synchronized to the MASTER timing. 
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Only the MASTER corrects his Receive 
phase. 
A long series of tests conducted by 
DiI and eae have shown that 

or opera in rapidly changing 
conditions, it is tig a good policy to adjust 
packet length automatically. Simulations 
and on-the-air testing showed the optimum 
HF packet length to be about one second. 
To compensate for varying conditions, 
PACTOR varies the number of data 
characters in the data block, but does not 
change any of the synchronous timing 
parameters. PACTOR determines the 
proper baud rate to use based on the 
accuracy Of bit transitions and the link 
error statistics. 


Data blocks have CRC-16 checking as is 
done in AX25 packet. This is much more 
robust than the parity bits FEC used in 
AMTOR. 


The data field of the PACTOR packet can 
contain any digital information; the format 
of the codes is specified in the status byte 
At the present time the choice is between 
: as and Huffman compressed 7 bit 


Authorization 


The US FCC regulations specify that 
Baudot or ASCII codes may be used for 
data transmission, The 8 bit ASCII text 
transmitted by PACTOR is closer to ‘pure 
ASCII’ than the bit-stuffed HDLC used by 
AX25 packet, so there should be no 
question of the legality of this mode. The 
compressed PACTOR data mode uses 
ASCII characters encoded in a channel- 
capacity-enhancing format which still 
meets the intent of the regulations. The 
regulations regarding amateur 
transmissions require that there be no 
intent to obscure the data transmitted. The 
Huffman encoding scheme is published as 
an appendix to this article. It seems 
reasonable to me to consider that encoding 


for spectrum efficiency using a widely 
published encoding scheme shows no 
intent to encrypt the content of the data 
transmission and is therefore allowable 
under US regulations. 


Performance 


PACTOR achieves good throughput 
during poor HF conditions by a variety of 
techniques. The actual baud rate is kept 
low - the same as AMTOR. This is one 
third the rate of typical HF AX.25 packet 
operation. From another point of view, 
AMTOR and PACTOR bits are three 
times as long as 300 baud HF packet bits, 
thus providing much increased protection 
from the bit smearing caused by multipath 
propagation, 

A doubling of the throughput compared to 
AMTOR results from sending longer 
blocks of data (but still short enough to 
cope with most fades) thus reducing the 
percentage of overhead carried. In 
addition, the ability to automatically 
double the data content of each block 
under favorable conditions provides a 
considerable increase in efficiency. 


Finally, encoding ASCII text (7 bit 
characters) using Huffman codes increases 
throughput by an average of at least 70 
percent. 


Memory-ARQ _ 


A significant feature of PACTOR is 
Memory-ARQ. Copies of the repeated 
reception of the same packet which fails 
the CRC are aggregated in memory and 
are summed individually for each bit. The 
aggregate of all unsuccessful transmissions 
is decoded which effectively increases the 
signal to noise ratio by about 15 dB. This 
PACTOR feature is hardware dependent 
and prevents the proper implementation of 
PACTOR as a software. only upgrade to 
packet or AMTOR equipment. 


The combination of the above factors 
provides a protocol which can provide a 
throughput nearly equal to HF packet in 
the best of conditions, and much better 
throughput than packet during typical 
conditions. Compared to AMTOR, the 


throughput in good conditions is up to four 
times as great. During the poorest of 
conditions, throughput is considerably 
better than AMTOR because of the 
CRC-16 error checking and Memory-ARQ 
capabilities. 


Appendix: PACTOR Huffman 
code 


Huffman coding Is relatively indifferent to 


differences between red and theoretical 
alphabet character frequencies, so that 
similar good results are obtained in 
German and English plain text. The 
compression factor attained with ASCII 
amounts to about 1.7, resulting in an 
average of 4.5 bits per character. A greater 
compression factor would require 
considering the statistical relationships 
between the individual characters (Markov 
encoding). 


Code in order of frequency, LSB (sent 
first) on the left: 


Character ASCII Huffman 

space 32 10 

e 101 011 

n 110 0101 

105 1101 

r 114 1110 

t 116 00000 

S 115 00100 

d 100 »=00111 

a 97 01000 

u 117 1111.1 

1 108 000010 

h 104 000100 

g 103 000111 

m 109 001011 

<CR> 13 001100 

<LF> 10 0071101 

0 111 010010 

C 99 010011 

b 98 0000110 

f 102 0000111 

w 119 0001100 

D 68 0001101 

k 107. = 0010101 

z 122 1100010 

P 46 1100100 
44 1100101 
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11'11011 
00’101001 
11000000 
11000010 
11000011 
11000111 
11001100 
11001111 
lIllloool 
11’110010 
11’110100 
000101000 
000101100 
001010000 
110000010 
110011011 
110011100 
110011101 
111100000 
111100110 
111100110 


0001010010 
0001010100 
~01010101 
0001010110 
0001011010 
0001011011 
0001011100 
0001011101 
0001011110 
0001011111 
0010100010 
1100000110 
1100000111 
1100011000 
1100011001 
1100011010 
1100110100 
1100110101 
1111000010 
1111010110 
1111010111 
00010100110 
00010100111 
00010101111 
00101000111 
11110011101 
11110011110 
001010001100 
110001101100 
110001101101 


eM, Ovte 


bee 


SR Se 


<US> 

<GS> 

<ESC > 
<EM> 
<CAN> 
<ETB> 
<SYN> 
<NAK> 
<DC4> 
<DC3> 
<DC2> 
<DC1> 
<DLE> 
<RS> 

<SI> 

<SO> 

<FF> 

<VT> 

<HT > 
<BS> 

<BEL> 
<ACK> 
<ENQ> 
<EOT> 
<ETX> 
<STX> 
<SOH > 
<NUL> 
<SUB> 


NOrNW BUI co WwW 


(>>) 


110001101110 
111100001100 
111100111001 
111100111110 
111100111111 
0001010111000 
0001010111001 
0001010111010 
0001010111011 
0010100011011 
00101000110101 
111100001'10100 
11110000110101 
001010001 101000 
001010001101001 
110001101111000 
110001101111001 
110001101'1111010 
110001101'111011 
110001101111100 
110001101111101 
110001101111110 
110001101111111 
111100001101100 
111100001101101 
111100001101110 
111100001101111 
111100001110000 
111100001110001 
111100001110010 
111100001110011 
111100001110100 
111100001110101 
111100001110110 
111100001110111 
111100001111000 
111100001111001 
111100001111010 
111100001111011 
111100001111100 
111100001111101 
111100001111110 
111100001111111 
1111.00112000000 
111100111000001 
111100111000010 
111100111000011 
111100111000100 
111100111000101 
111100111000110 
111100111000111 


